由於ScyllaDB不像關聯性資料庫一樣支援join，所以必須在建立table時實作反正規劃。
把必須的欄位放到table內，然後透過Materialized Views來查詢。

Materialized View實際上就是另一個table，資料來源是由原本的table擷取所需的欄位，依據新的query語法需求來選擇partition key和排序。
view的PK必須包括table的PK，並且View的PK只能包括一個非Primary key的欄位。說起來十分饒舌，直接用範例說明。
首先原本的table,id是PK。

今晚我想來點view，name當PK。

結果失敗，因為view的PK必須包括原本的table painting的PK，也就是id。
接著再試試用name，id，time當PK。

結果又錯了。因為name與time在painting裡都不是PK，view只容許放一個非PK的值在view的PK裡頭。
所以正確的做法如下。

Scylla更新資料的順序如下。

從圖片可以看出，資料是先寫入table之後才去做update view的動作。
這樣的做法是為了避免同時更新Materialized View與table時服務過載而影響了table的可用性。
View的使用也不會必然依循CL的設定。就算設定是quorum，實際上並不會等到真的有過半的view replica回應才完成。
除此之外，既然view是被認定為另一個table，擁有自己的partition key。那麼在設計時，也必須注意不要造成large partition的情況發生，以免影響效能。